The brokerage industry can be highly competitive. Strategically, brokerage firms often attempt to gain a larger market share of customers by offering lower transactions fees. It is highly desirable for brokers to continually find ways to reduce their operating costs associated with fulfilling or transacting customer orders for financial instruments, such as stocks, bonds, options, and mutual funds, while maintaining or improving their ability to serve customers by reliably fulfilling customer orders on a timely basis.
Typically, brokerages accept or input customer orders via their systems and then forward the orders to an existing order fulfillment system or legacy system for subsequent transaction of the customer order. Typically, the order fulfillment system is a legacy system that has been reliably operating for many years, and legacy systems are rarely modified to perform significantly new functions to avoid potentially undesirable consequences to the overall system performance. However, when a customer order for a financial transaction has flaws, the existing order fulfillment system cannot fulfill the customer order and the subsequently unfulfilled customer order is returned by the existing order fulfillment system to the broker along with a financial charge for incurred processing time on the existing order fulfillment system. In such a situation, the customer order may not be fulfilled on a timely basis and undesirable costs may be incurred in the attempt to transact the customer order.
Typically, a programming application, written in a computer programming language, includes nested programming logic having if/then programming statements each implementing business logic rules for a specific broker. The programming application is subsequently compiled into an executable file which is then used by a central processing unit to check the conformance of customer orders. Typically, the implemented business logic rules are relevant for the business needs of a specific broker. Frequently, the programming application requires modifications to the implemented business logic rules, in which case, the entire program needs to be reviewed by an expert computer programmer and recompiled and re-tested to ensure suitable and reliable operation. However, the prior art applications are frequently difficult to maintain typically because expert computer programmers do not remain with the same employer, or documentation of the programming is severely lacking in depth. Therefore, new programmers face the task of learning a new programming language to remove, add, modify business logic rules and re-test the updated computer application. Additionally, the known prior art computer applications require that all of the rules need to be serially or sequentially applied in an inflexible manner to each customer order. This inflexibility leads to an accumulation of unnecessary processing time and effort on the behalf of a computer system because not all of the rules may be required to check whether data elements of each customer order conform to the business logic rules.
Another problem experienced with on-line transaction of customer orders is that even though the customer orders may appear to be acceptable to a existing order fulfillment system, the customer order may not be appropriate with respect to an investment profile or preferences of the customer. This can lead to brokers transacting inappropriate types of customer orders for some customers. Some jurisdictions require brokers to know the investment tolerances or profiles of their clients before transacting customer orders, which is known as ‘know your customer’ rules.
In conclusion, prior art systems codify the business logic rules into a single source code file and subsequently compile the source code file to create a single executable file. However, when the business logic rules require to be changed, a computer programmer is required to examine the original source code, ascertain the extent of the required changes, test, and debug the new code, followed by the required compilation to create an updated or revised executable file. Disadvantageously, this required the talents of an experienced programmer, and if that programmer were new to the organization, then more time would be required to understand the original source code especially if the original source code were not properly documented. Also, even an experienced programmer would not typically appreciate or understand the requirements of a business and the types of business logic rules that would be required to check conformance of customer orders. Disadvantageously, the business logic would change periodically to suit the needs of regulatory agencies or stock market conditions, which would place a undue burden on the programmer attempting to adapt the source code to newly developed business logic rules.